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I.  Introduction:  KRS,  APE-II,  and  Project  Juniper 

In  late  December  of  1984  researchers  at  RADC's  Artificial 
Intelligence  (AI)  Laboratory  were  involved  in  the  critical 
analysis  of  an  Al-based  tactical  mission  planning  system  and 
its  integrated  interface.  Laboratory  engineers  from  the  Naval 
Ocean  Systems  Center  (NOSC)  of  San  Diego,  California  proposed  a 
coordinated  research  effort  to  investigate  and  test  joint 
mission  planning  capabilities  of  current  RADC  and  NOSC 
prototype  systems.  Both  laboratories  had  separately  been 
sponsoring  research  to  originate  technology  to  support 
development  of  air  strike  planning  aids.  These  aids  were,  of 
course,  targetted  at  assisting  their  respective  branches  of  the 
armed  services.  However,  since  the  operational  Air  Force  and 
Navy  may  need  to  support  each  other  in  air  strike  missions,  the 
abilities  of  planning  systems  for  each  service  must  be  mutually 
supportive.  RADC  and  NOSC  laboratory  personnel  first  met 
formally,  and  discussed  technical  objectives  of  the  joint 
effort,  in  February  of  1985  at  RADC. 

Initiated  as  Project  Juniper  under  the  Joint  Directorate 
of  Laboratories  (JDL)  Command,  Control,  and  Communication 
technology  program,  the  specific  objective  of  the  coordinated 
effort  was  to  "demonstrate  the  feasibility  of  using  distributed 
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expert  system  decision  aids  to  support  the  planning  of  joint 
Air  Force  and  Navy  strike  missions." 

RADC's  mission  planner  is  called  KRS  (Knowledge-Based 
System).  NOSC's  carrier-based  planner  is  called  ASPA  (Air 
Strike  Planning  Advisor).  KRS  and  ASPA,  described  only  briefly 
in  this  paper,  are  the  interim  results  of  research  efforts  and 
are  not  field-ready  developments. 

KRS  and  the  Integrated  Interface 

KRS  is  a  generic  knowledge-based  expert  system  developed 
to  demonstrate  expert  system  technology  applied  to  Air  Force 
tactical  mission  planning.  It  is  written  in  LISP  and  runs  on 
the  Symbolics  3670  Lisp  Machine. 

KRS  can  be  used  to  plan  missions  interactively  with  a 
user,  as  a  data  base  and  a  plan  verifier,  or  can  be  used  to 
automatically  generate  Air  Tasking  Orders  (ATOs)  with  minimal 
human  input.  The  interactive  and  autoplanning  modes  of  use  can 
be  freely  mixed.  As  a  data  base,  KRS  has  information  about 
resource  availability  and  allocation,  target  defense  status, 
and  some  bits  of  information  about  weather  conditions.  Facts 
about  different  aircraft,  ordnance,  and  target  types  can  also 
be  accessed.  In  its  plan  verification  role,  KRS  checks  to  make 
sure  a  mission  plan  is  logically  consistent  (e.g.  the  aircraft 
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specified  for  use  are  available  at  the  base  specified)  and  does 
not  violate  current  airwar  doctrine. 

A  I<RS  screen  display  is  shown  on  page  5.  The  full-screen 
display  is  partially  covered  by  a  smaller  area  (a  "window") 
labeled  'OCA1003'.  The  larger,  full-screen  display  is  the 
toplevel  KRS  window.  It  keeps  a  list  of  all  of  the  missions 
planned  so  far  (or,  all  of  the  missions  planned  that  are 
currently  of  interest  to  the  user),  and  has  an  area  for  typed, 
user  input.  The  smaller,  mission  window  has  a  number  of  slots 
that  must  be  given  values  in  order  to  fully  describe  an 
Offensive  Counter  Air  (OCA)  mission.  Mission  windows  each  have 
their  own  area  in  which  to  accept  typed,  user  input. 

Users  communicate  with  KRS  via  a  multi-media  interface 
that  utilizes  natural  language,  windows,  a  "mouse”  pointing 
device,  and  color  graphics.  The  natural  language  subsystem  is 
comprised  of  a  dictionary  driven  parser,  APE-II  (A  Parsing 
Experiment),  and  a  script  interpreter.  The  parser  and 
interpreter  work  to  develop  a  Conceptual  Dependency 
conceptualization  of  the  meaning  of  user  input  to  KRS.  For 
example,  the  sentence  "There  are  F-4C's  at  Hahn"  becomes: 

(‘EXISTS*  OBJECT  (F-4C  NUMBER  (‘PLURAL*)) 

LOC  (AT  PLACE  (HAHN))) 
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Here,  the  CD  primitive  '*EXISTS*'  implies  the  existence  of 
an  object.  The  roles  'OBJECT'  and  'LOC'  have  role  fillers  that 
describe  the  object  that  exists  and  its  location,  respectively. 


KRS  and  its  interface  were  developed  by  the  MITRE 
Corporation  in  Bedford,  Massachusetts  through  funding  from  Rome 
Air  Development  Center.  Both  are  described  in  much  more  detail 
in  [Dawson,  et  al ;  1987], 

ASPA 


NOSC's  expert  system,  called  ASPA  (Air  Strike  Planning 
Advisor),  supports  a  carrier-based  strike  at  a  land  target. 

The  computing  environment  of  ASPA  is  the  Xerox  1108  Dandelion 
Lisp  Machine.  The  first  air  strike  subtask  developed  under  the 
ASPA  project  was  weapons  loading,  or  weaponeering,  for  the  A-6 
attack  aircraft.  After  the  target,  strike  schedule,  and 
ordnance  have  been  specified,  expert  rules  generate  and  test 
possible  external  loads.  Constraints  that  limit  total  aircraft 
weight,  balance  the  weight,  minimize  drag,  and  specify 
allowable  physical  mounting  configurations,  must  be  adherred 
to . 


► 
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II.  scenario  of  Operational  Air  Force/Navy  Coordination 

The  major  obstacle  to  early  progress  in  this  effort  was 
defining  a  reasonable  scenario  depicting  coordinated  operations 
between  operational  Air  Force  and  Navy  forces.  Initial 
suggestions  for  the  coordination  of  forces  were  shot  down 
one-by-one  as  being  unrealistic.  One  possibility,  for  example, 
was  to  have  aircraft  from  one  service  refuel  aircraft  from  the 
other  in  order  to  allow  the  successful  completion  of  a  strike 
mission.  There  are  a  multitude  of  problems  with  that  idea: 
First,  it  is  almost  impossible,  physically,  for  a  plane  from 
one  service  to  refuel  a  plane  from  the  other.  The  Air  Force 
KC-10  is  the  only  tanker  equipped  with  the  two  types  of 
refueling  nodes  for  refueling  both  Air  Force  and  Navy  aircraft. 
The  Air  Force  KC-135  can  be  reconfigured  to  refuel  a  Navy  plane 
but  must  be  taken  out  of  service  for  maintenance  to  do  so. 

Also,  Air  Force  refueling  missions  are  not  planned  or  ordered 
by  Tactical  Air  Command  (TAC),  the  operational  component  which 
KRS  is  designed  to  assist.  Refueling  services  are  entirely 
under  the  aegis  of  Strategic  Air  Command  (SAC).  Although  it 
was  not  felt  to  be  necessary  to  go  strictly  "by  the  book", 
there  was,  of  course,  a  strong  desire  to  remain  within  the 
realm  of  believability. 
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In  discussions  with  operational  Air  Force  personnel,  the 
distinction  between  'joint'  and  'coordinated'  multiple-service 
missions  was  stressed.  'Joint'  mission  planning  implies  that 
some  of  the  assets  of  one  of  the  services  are  given  to  another 
service  and  are  under  their  direct  control.  Joint  mission 
planning  is  rare  since  neither  service  wants  to  give  up  control 
of  any  of  its  assets.  In  'coordinated'  missions,  each  force 
receives  their  orders  about  where  and  when  to  be  through  their 
usual  chain  of  command.  The  supported  force  plans  the 
operation  and  makes  the  specific  request  for  support  from  the 
planning  organization  of  the  other  service.  Sensitivity  to 
this  distinction  in  terms  increases  as  one  goes  down  the 
hierarchical  chain  of  command  in  either  branch  of  the  service. 

A  prevailing  difficulty  of  coordinated  air  strikes  is  the 
fact  that  missions  are  planned  at  two  different  command  levels 
within  the  Navy  and  the  Air  Force.  In  the  Air  Force,  plans  are 
made  at  the  numbered  Air  Force  level  and  disseminated  in  the 
ATO.  Mission  planning  in  the  Navy  is  done  at  a  lower  command 
level,  onboard  the  carrier.  In  addition  to  the  probable 
difficulties  caused  by  the  requirement  for  communication  and 
coordination  between  Air  Force  and  Navy  officers  of  different 
rank,  are  the  difficulties  associated  with  communication  with  a 
carrier  due  to  EMCON  (emissions  control)  status. 
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EMCON  is  important  to  the  Navy  because,  unlike  a  strike 
against  an  airbase,  an  air  strike  against  a  carrier  jeopardizes 
the  entire  base  of  operations.  In  the  interest  of  carrier 
self-preservation,  great  care  must  be  taken  in  the  use  of  radio 
communications.  But  radio-silence  inhibits  mission 
synchronization  and  is  prohibitive  of  mission  coordination. 
Additionally,  carrier  self-preservation  requires  keeping 
sufficient  forces  in  reserve  for  carrier  defense.  These 
measures  for  self-preservation  are  often  misunderstood  and 
perceived  as  a  lack  of  cooperation  by  members  of  other 
services . 

Apparently,  the  one  consistent  area  of  cooperation  between 
the  operational  Air  Force  and  Navy  pertains  to  the  use  of  the 
AWACS  (Airborne  Naming  and  Control  System)  .  Its  communication 
resources  allow  it  to  give  assistance  to  both  Air  Force  and 
Navy  aircraft.  For  this  reason,  coordination  involving  use  of 
the  Air  Force  AWACS  resource  was  considered  as  the  basis  for  a 
scenario.  (As  will  oe  seen  in  the  next  section,  AWACS  services 
were  not  used  in  the  final  demonstration.) 

Current  lack  of  coordination  between  the  operational 
services  did  not  diminish  the  value  of  the  objective  of  Project 
Juniper,  that  is,  to  demonstrate  distributed  expert  systems  in 
support  of  coordinated  Air  Force/Navy  air  strike  planning. 
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Operational  service  people  invariably  beleive  in  the  necessity 
of  inter-service  operations  but  find  them  improbable  under 
current  political  and  practical  (ie.  communications,  carrier 
self-preservation  requirements,  etc.)  conditions.  Research 
laboratories  can  play  an  important  role  in  making  such 
coordination,  in  the  practical  aspect,  feasible. 

Two  excellent  activities  for  obtaining  operational 
information  were  the  Bold  Eagle  86  Exercise  held  in  late 
October  of  FY-86  and  the  Battle  Staff  Course  taught  at  the  USAF 
Air  Ground  Operations  School  (AGOS),  Hurlburt  Field,  Florida. 

Lt  Kevin  Benner  and  Ms.  Sharon  Walter  were  observers  for 
three  days  of  the  Command  Post  Exercise  (CPX)  portion  of  Bold 
Eagle.  The  CPX  consisted  of  the  planning  and  tasking  portions 
of  the  operational  tactical  environment.  Participants  in  the 
Bold  Eagle  CPX,  and  in  the  Live  Fly,  or  Flight  Exercise  (FTX) , 
of  the  following  week  included  Air  Force,  Army,  Navy  and  Marine 
units.  As  CPX  observers,  Lt  Benner  and  Ms.  Walter  were  free  to 
observe  and  interact  with  staff  officers  within  the  Tactical 
Air  Control  Center  (TACC)  on  a  non-interference  basis. 

It  is  interesting  to  note  that  two  computerized  systems, 
CAFMS  (Computer  Assisted  Force  Management)  and  JAMPS  (JIMTACCS 
Automated  Message  Processing  System)  were  in  use  during  the 
exercise.  CAFMS  is  basically  a  database  management  system. 
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The  very  carefully,  hand-prepared,  hand-checked  and 
double-checked  ATO  is  typed  on  CAFMS  into  templates  which  are 
not  unlike  KRS  mission  templates.  The  system  complains  when 
resources  have  been  overexpended.  After  the  ATO  has  been 
entered,  it  can  be  sent  via  JAMPS,  in  full  or  in  part,  to  all 
appropriate  offices.  (One  of  the  complaints  that  the  Navy  has 
about  working  with  the  Air  Force  is  that  ATOs  are  sent  in  their 
entirety  to  all  involved  parties.  Navy  carriers  receive  the 
entire  ATO.  Communications  are  slow.  The  ATO  transmission 
holds  other  communication  up  for  long  periods  of  time, 
increasing  the  opportunity  for  enemy  detection  and  carrier 
location  tracing.)  JAMPS  sends  messages  to  specified  receivers 
in  the  JINTACCS  (Joint  Interoperability  of  Tactical  Command  and 
Control  System)  format  (intended  to  be  the  all-service 
standard) . 

Critiques  of  the  CPX,  filled  out  by  exercise  participants, 
demonstrated  the  willingness  of  operational  personnel  to  accept 
computerization  of  their  operational  environment.  One  such 
critique  recommended  "CAFMS  terminals  at  each  duty  desk."  This 
suggestion  seems  inappropriate  in  view  of  the  type  of  task 
assistance  provided  by  CAFMS,  but  may  be  an  indication  of  the 
kind  of  acceptance  that  TEMPLAR  will  experience.  TEMPLAR 
(Tactical  Expert  Mission  Planner)  is  a  research  project  that  is 
extending  and  fortifying  the  technology  developed  in  KRS.  It 
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is  intended  to  bring  computerized,  intelligent  mission  planning 
capabilities  closer  to  field  deployment.  TEMPLAR  is  scheduled 
to  be  tested  at  the  USAF  Blue  Flag  Exercise  in  September  1987. 

The  three-week  long  Battle  Staff  Course  is  taught  on  a 
regular  basis  at  AGOS.  It  provides  information  on  the  tactical 
battle  management  functions  within  the  Tactical  Air  Control 
System  (TACS)  with  emphasis  on  the  real-time  employment  of 
joint  Air  Force/Army  air  and  land  resources.  Battle  Staff 
faculty  stress  that  the  structure  of  the  tactical  environment 
as  it  is  taught  is  generic,  with  each  existing  such  environment 
demonstrating  wide-ranging  variation  from  their  model.  While  a 
few  course  participants  complained  that  course  content  was 
often  inaccurate  or  outdated,  most  felt  that  an  adequate  model 
was  presented. 

The  Air  Force  and  Army  have  a  very  detailed  and  effective 
system  of  cooperation,  especially  as  demonstrated  by  J-SEAD 
(plans  for  Joint  Suppression  of  Enemy  Air  Defense) .  The 
minimal  participation  of  Navy  and  Marine  personnel  as  either 
students  or  briefers,  and  comments  by  the  lone  Marine  speaker, 
demonstrate  the  strained  relations  existing  between  the 
operational  Air  Force  and  the  Navy/Marines.  The  basic  cause 
for  the  emotionalism  was  characterized  as  a  case  of  differing 
interpretations  of  Air  Force  and  Navy/Marine  responsibilities 
in  the  tactical  environment.  The  Marine  speaker  described  the 
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functional  (Air  Force)  separation  of  responsibility  and  the 
service  (Navy /Mar ine )  understanding  of  the  separation  of  power. 
Functional  responsibilities  are  divided  into  air,  ground,  and 
naval  functions.  Each  services'  air  assets,  according  to  Air 
Force  doctrine,  are  the  responsibility  of  the  Air  Component 
Commander  (usually,  but  not  necessarily,  an  Air  Force  person), 
similarly  with  ground  and  naval  assets.  According  to 
Navy/Marine  interpretation  of  Joint  Chiefs  of  Staff  (JCS) 
Publications,  each  service  maintains  full  responsibility  and 
control  of  their  respective  assets  (see  the  pictoral 
demonstration  in  Figure  2  of  the  differing  interpretations) . 


Functional  Interpretation  Service  Interpretation 

of  Responsibilities  of  Responsibilities 


Figure  2 


Attendance  at  the  AGOS  Battle  Staff  course  provided 
valuable  information  on  the  operational  environment,  including 
the  field-related  jargon  and  copious  acronyms,  for  which  RADC 
produces  computerized  assistance.  While  much  of  the  course  had 
no  specific  relevance  to  Air  Force/Navy  relations,  sessions 
provided  valuable  information  on  the  operational  Air  Force 
environment . 
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III.  Effort  Activities  and  Results 

In  early  December  of  1985,  an  interim  project  presentation 
to  the  Project  Juniper  sponsors,  the  Decision  Aids  subpanel  of 
the  JDL ,  demonstrated  the  successful  redefinition  of  the  KRS 
domain  setting,  and  a  scenario  demonstrating  the  "feasibility" 
of  coordinated  Air  Force/Navy  mission  planning.  At  that  time 
KRS  and  ASPA  did  not  technically  communicate  directly  with  one 
another  since  a  means  of  communication  between  the  two  types  of 
hardware  (Xerox  and  Symbolics  Lisp  Machines)  and  software  had 
not  yet  been  completed.  Eventually,  the  exchange  of 
information  between  ASPA  and  KRS  took  place  across  an  ethernet 
connection  using  the  TCP/IP  communication  protocol  (Figure  3, 
on  the  next  page) . 
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AS  PA 


KRS 


(Symbolics  3670) 


TCP/IP 


10  Mbps  Ethernet 


(Xerox  1108) 


TCP/IP 


Figure  3 


The  scenario  finally  settled  on  is  based  in  Southeast 
Asia.  According  to  the  scenario,  Clark  Air  Force  Base  and 
Subic  Bay  have  been  closed.  Air  Force  resources  at  Guam  and 
two  Navy  task  forces  with  the  USS  Enterprise  and  the  USS  Carl 
Vinson  are  to  be  employed.  The  tasking  directive  to  the  TACC 
requests  strikes  on  four  targets.  KRS  is  used  to  successfully 
plan  the  assignment  of  Air  Force  resources  at  Guam  to  the 
targets  but  then  determines  that  refueling  services  are 
available  to  support  only  three  of  the  sorties.  Via  KRS  (to 
ASPA) ,  strike  support  is  requested  from  the  Navy.  Navy 
planners,  through  ASPA,  respond  affirmatively  and  identify 
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available  aircraft  and  the  launch  platform,  window,  and 
location.  KRS  is  then  used  to  replan  the  four  strike  missions 
using  both  Air  Force  and  Navy  assets,  and  sends  a  message  to 
ASPA  identifying  the  exact  target  to  strike,  the  desired  damage 
level,  and  the  time-over-target  (TOT).  On  the  Navy  side,  ASPA 
is  used  to  complete  the  Navy  portion  of  the  plan  and  returns 
the  results  to  KRS.  With  final  Air  Force  and  Navy  plan 
coordination  completed,  KRS  incorporates  the  ASPA  plan  into 
their  Air  Tasking  Order. 

For  the  most  part,  transforming  the  domain  of  scenario 
operation  from  the  Fulda  Gap  region  of  western  Europe  to  the 
Southeast  Asian  scenario  consisted  only  of  changing  the 
database  information.  The  relative  ease  of  transportation 
demonstrated  what  was  considered  to  be  an  appropriate 
independence  in  the  KRS  software  structure,  of  the  knowledge 
base  from  the  control  structures.  Other,  more  significant  and 
telling  software  alterations  were  made  later.  For  instance, 
the  ability  to  quantify  resources  at  airbases  was  added. 
Previous  to  this,  an  unlimited  number  of  aircraft  could  be 
detailed  from  any  airbase.  The  system  knew  of  no  bounds  on  its 
resources.  Alterations  to  the  system  allowed  it  to  keep  track 
of  its  resources  and  provide  notification  when  they  were  used 
up.  (The  contractor  developing  KRS,  MITRE,  also  had  this 
feature  fixed  in  the  next  released  version.) 
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One  nagging  roadblock  in  the  realistic  portrayal  of 
coordinated  mission  planning  had  been  the  fact  that  different 
planning  tasks  exist  at  different  command  levels  in  each  of  the 
services.  The  level  of  planning  demonstrated  by  XRS  is 
shore-based  in  the  Naval  command  structure.  The  planning  task 
level  for  which  ASPA  was  developed  is  at  carrier  level,  lower 
in  the  hierarchical  command  structure.  ASPA  should  be 
receiving  information  of  the  type  produced  by  KRS  from  its 
superior  command  level  before  proceeding  with  its  task  of 
planning  the  details  of  specific  missions.  The  decision,  then, 
was  to  develop  a  version  of  KRS  with  a  database  of  Naval  assets 
(carriers  and  Navy  aircraft,  instead  of  airbase^  and  Air  Force 
aircraft),  and  Navy-specific  rules  and  slot  constraints  (ex. 
carriers  launch  aircraft  only  within  the  limits  of  narrow, 
time-constrained  "launch  windows").  Additional  changes 
included  relabeling  screen  display  items  to  give  them  more  of  a 
Navy  flavor,  and  providing  the  system  with  the  notion  of  moving 
airbases  (ie.  carriers).  Thus,  in  the  final  demonstration  of 
coordinating  systems,  respective  Naval  and  Air  Force  KRSs 
interact  directly,  and  ASPA  receives  its  planning  directives 
and  data  from  the  Navy-KRS .  The  structure  of  the  communication 
among  systems  is  shown  in  Figure  4. 


Air  Force 


Navy 


KRS 

(TACC-Based) 


Figure  4 
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-  - 


ASPA 
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A  common  window  for  interaction,  the  "Juniper  window",  was 
developed  to  display  the  passage  of  messages  between  KRS  and 
Navy-KRS. 

To  assist  in  the  development  of  the  Navy-KRS,  a  Frame 
Editor,  called  FED,  was  developed.  FED,  based  on  the  Frame 
Representation  Language  (FRL)  ([Roberts  and  Goldstein;  1977]), 
guides  a  user  in  making  changes  to  the  planning  domain.  The 
RADC  Technical  Memorandum,  "Database  Editor  for  a  Frame  Based 
System"  ( [Anken;  1986]),  describes  the  system.  A  copy  of  the 
program  was  delivered  to  NOSC  Project  Juniper  researchers  to 
allow  continued  refining  of  Navy-KRS. 


APE-II :  Domain  Transfer  and  Analysis 

Porting  of  APE-II  to  the  Navy  domain  was,  fortunately, 
largely  a  matter  of  word  replacement  in  the  dictionary.  Navy 
domain  words  were  attached  to  the  word  definitions  already  in 
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the  system.  Structuring  of  new  word  definitions  was  not 
necessary.  Neither  was  it  necessary  to  extend  the  form  of 
questions  that  were  allowed,  since  similar  forms  of  questions 
are  asked  of  a  Navy  mission  planner  and  an  Air  Force  mission 
planner  (eg.  "What  aircraft  are  at  the  airbase?";  "What 
aircraft  are  on  the  carrier?").  Defining  Navy  domain  words 
exactly  like  similar  words  in  the  Air  Force  domain,  or  defining 
them  as  synonyms  (using  the  facility  which  provides  this 
capability) ,  allowed  development  of  a  front-end  for  the  Navy 
planning  systems  with  pretty  much  the  same  breadth  of 
understanding  as  the  original  KRS.  It  is  fortuitous  that  the 
domains  were  similar  enough  to  allow  this  course  of  action 
because  semantics-based  understanding  systems  are  known  to  be 
much  more  difficult  to  extend  or  port  than  syntax-based 
systems.  Some  of  the  difficulty  is  evident  from  an  analysis  of 
the  KRS  interface. 

Input  interpretation  is  dictionary-driven  by  APE-II.  As 
each  word  is  processed,  its  dictionary  definition  is  copied 
unco  a  list  representing  concepts  that  are  currently  in  focus. 
The  definition  of  a  word  is  largely  determined  by  its  location 
in  a  hierarchy  of  concepts  similar  to  the  frame  hierarchy  of 
the  KRS  Knowledge  base.  While  items  in  the  frame  hierarchy  are 
mainly  physical  objects  or  names  for  groups  of  similar  physical 
objects  (ie.  "Hahn",  "airbase",  "location",  etc.),  items  in 
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the  hierarchy  of  dictionary  terms  are  mostly  conceptual.  For 
example,  'reach',  'fly',  'go',  or  'carry'  are  examples  of  the 
*PTRANS*  concept.  (Classically  in  CD  theory,  a  PTRANS  refers 
to  a  physical  transfer  of  something.)  As  another  example, 
'country'  is  conceptually  a  kind  of  *LOC*  (ie.  location). 
Figure  5  shows  part  of  the  hierarchy  of  concepts.  The  topmost 
concepts  of  the  hierarchy  (the  'primitive'  concepts)  are: 
*LOCSPEC* ,  *ACT* ,  *STATE*,  *  ARTICLE*,  *CONREL* ,  *GROUtP*,  *?*, 
*PLURAL* ,  *ATTRIBUTE* ,  *RELPRO* ,  *OBJECT*,  *GOAL* ,  *PLAN* ,  and 
*MODE-ATTR* .  (Note  that  these  are  similar  but  not  the  same  set 
of  primitives  that  are  used  by  Roger  Schank  to  describe 
Conceptual  Dependency  Theory  as  he  defined  it.  Schank 's  set  of 
eleven  primitives  were  used  to  clarify  the  theory  and  not 
necessarily  intended  to  be  the  standard  set  for  all 
applications.)  The  point  to  be  made  here  is  that  it  can  be 
quite  difficult  to  know  where  to  install  new  words  in  the 
hierarchy  without  having  all  the  information  about  the  concept 
meanings  that  the  developers  intended. 


19 


20 


Eventually,  the  concepts  associated  with  the  input,  and 
word  sense  expectations,  are  resolved  into  a  representation  of 
the  input.  There  may  be  more  than  one  word  sense  for  a  word 
and  each  word  sense  has  a  set  of  expectations  that  help  the 
process  towards  a  final  resolution.  To  illustrate,  the  lone 
word  sense  for  the  word  "the"  is: 

(SENSE  (*DEF*) 

EXPECTATIONS 

((IF  (MODIFIES  (OR  *PP* 

* EVE NT* 

♦RELATION* 

SCRIPT 

*BPRED* 

*TPRED* ) ) 

THEN  ( (SLOTS  (*  REF) ) ) ) 

Thus,  the  sense  of  the  word  "the"  represented  by  ' *DEF '  is 
the  appropriate  sense  to  use  if  it  modifies  a  concept  that  is 
derived,  in  the  concept  hierarchy,  from  one  of  *PP*,  *EVENT*, 
♦RELATION*,  SCRIPT,  *BPRED* ,  or  *TPRED* .  Since  "airbase"  is 
derived  from  *PP*  (ie.  "airbase"  is  a  'picture-producer'),  the 
simple  phrase  "the  airbase"  becomes: 


(AIRBASE  REF  (*DEF*) ) 


Responses  to  questions  are  made  by  comparing  the 
conceptual  representation  of  the  question  to  each  member  of  a 
set  of  question-answer  pairs.  Each  question-answer  pair 
consists  of  a  pattern  to  match  against,  and  an  associated 
action  to  execute.  Patterns  are  made  general  enough  to  match 
against  a  set  of  similar  inputs.  A  simple  example  would  oe  the 
pattern  that  matches  against  the  representation  for  both,  "How 
many  F-4C's  are  at  Hahn"  and  "How  many  F-lllE's  are  at 
3itburg."  Question-action  pairs  are  ordered  so  that  the  best 
match  for  an  input  will  be  found  before  less  well-matched,  but 
conceivably  appropriate,  pairs.  Note  that,  again,  a  very  good 
understanding  of  the  historical  development  of  the  interface  is 
necessary  to  extend  it. 
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IV.  Summary 


Work  on  Project  Juniper  at  RADC  ended  in  September  1986. 
The  KRS  planning  system  and  its  natural  language  interface  had 
been  ported  to  the  new  domain  of  Southeast  Asia.  Hardware 
incompatibilities  (NOSC's  Xerox  1106;  RADC 1 s  Symbolics  3670) 
and  software  incompatibilities  (Interlisp;  Zetal isp) *  were 
successfully  overcome. 

ASPA  and  KRS  planning  level  differences  were  surmounted  by 
the  port  of  KRS  to  still  another  domain.  Navy  mission  planning, 
and  using  this  Navy-KRS  to  act  as  the  Navy,  land-based  planner 
one  level  above  ASPA-level  planning.  Modifications  to  Navy-KRS 
were  then  made  to  allow  the  airbase  (carrier)  locations  to  be 
dynamic.  The  "Juniper  window"  displays  the  messages  passed 
between  KRS  and  Navy-KRS. 

The  process  of  porting  KRS  and  its  interface  to  two  new 
domains  greatly  added  to  the  involved  researchers' 
understanding  of  the  planning  and  natural  language  software.  A 
paper  describing  the  system  was  presented  at  the  AGARD  Avionics 
Panel  Symposium  in  1986  ([Benner  and  Hilton;  1986]).  [Anken; 
1986]  describes  software  that  was  designed  and  constructed  to 
assist  in  porting  the  planner. 
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The  Project  Juniper  goal  of  demonstrating  Air  Force  and 
Navy  mission  planning  systems,  operating  to  plan  missions 
cooperatively,  has  been  successful.  Mission  planning 
coordination  was  demonstrated  on  a  technical,  computing  level. 
The  authenticity  of  operational  Air  Force/Navy  mission 
coordination  remains,  of  course,  beyond  our  control  and  in 
question. 

The  KRS  and  Navy-KRS  systems  have  been  delivered  to  NOSC 
where  work  continues  on  fine  tuning  and  extending  system 
coordination  capabilities. 


V.  Commentary 


Mutual  Naval  Laboratory  and  Air  Force  Laboratory  benefits 
were  derived  from  coordinated  research  between  participants  in 
this  project  and  NOSC  researchers  working  on  Project  Juniper. 
The  coordination  provided  us  with  assistance  in  defining  the 
new  KRS  planning  domain  of  Southeast  Asia  and  the  extended  goal 
of  redefining  the  system  to  suit  a  Navy  domain.  Beyond  the 
technical  success  achieved,  the  basis  of  a  relationship  for 
future  work  with  NOSC  has  been  developed. 

Individual  researcher  understanding  of  the  operational 
environment  for  which  RADC  is  tasked  with  developing  technology 
was  improved  in  the  process  of  collecting  domain  data  for  this 
effort.  The  AGOS  Battle  Staff  Course  was  an  excellent  source 
of  general  information  and  contacts  (i.e.,  the  other  students) 
for  future  reference.  The  AGOS  faculty  should  be  considered  a 
friendly,  knowledgeable,  and  available  resource  for  future 
work.  The  RADC  Intelligence  Office  (IN)  provided  enthusiastic 
assistance  in  researching  documentation,  as  did  the  RADC 
Technical  Library.  Still,  additional  resources  of  operational 
information  require  development. 
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One  final  word  regarding  the  difficulty  of  porting  or 
extending  a  semantics-based  Natural  Language  interface:  Much 
of  the  difficulty  is  based  on  the  requirement  for  total 
understanding  of  the  historical  development  of  a  system.  This 
difficulty  is  often  considered  to  be  a  sufficient  reason  to 
dismiss  inclusion  of  semantic  interpretation  in  an  interface. 
However,  the  gain  in  system  understanding  of  Natural  Language 
to  be  made  in  the  future  is  estimated  to  be  considerable.  Here 
then,  is  a  possible  application  for  RADC's  Knowledge-Based 
Software  Assistant  (KBSA)  [Green,  et  al;  1983].  The  KBSA  is  a 
"knowledge-based,  life-cycle  paradigm  for  the  development, 
evolution,  and  maintenance  of  large  software  projects."  The 
KBSA  is  being  developed  to  provide  a  corporate  memory  of  the 
software  development.  It  will  act  throughout  the  software  life 
cycle  as  a  knowledgeable  software  assistant.  Development  of 
semantic  interpreters  using  the  KBSA  software  development 
paradigm  should  provide  software  extensibility  and  portability. 
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ACRONYMS 


AGOS  Air  Ground  Operations  School 

ATO  Air  Tasking  Order 

APE-II  A  Parsing  Experiment 

ASPA  Air  Strike  Planning  Advisor 

A. VACS  Airborne  Warning  and  Control  System 

CAFMS  Computer  Assisted  Force  Management 

CPX  Command  Post  Exercise 

EMCON  Emissions  Control 

FED  Frame  Editor 

FRL  Frame  Representation  Language 
FTX  Flight  Exercise 

JAMPS  JINTACCS  Automated  Message  Processing  System 

JCS  Joint  Chiefs  of  Staff 

JINTACCS  Joint  Interoperability 

of  Tactical  Command  and  Control  System 

JDL  Joint  Directorate  of  Laboratories 

J-SSAD  Joint  Suppression  of  Enemy  Air  Defense 

JTF  Joint  Task  Force 

XBSA  Knowledge-Based  Software  Assistant 
KRS  Know  ledge -Based  Replanning  System 
NOSC  Naval  Oceans  Systems  Command 
OCA  Offensive  Counter  Air 
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POL  Petroleum,  Oil,  Lubricant 

RADC  Rome  Air  Development  Center 

SAC  Strategic  Air  Command 

TAC  Tactical  Air  Command 

TACC  Tactical  Air  Control  Center 

TACS  Tactical  Air  Control  System 

TEMPLAR  Tactical  Expert  Mission  Planner 

TOT  Time-Over-Target 
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MISSION 

of 

Rome  Air  Development  Center 

RA VC  plan s  and  executes  research,  dtve.lopme.nt,  test 
and  selected  acquisition  programs  In  support  of 
Command,  Control,  Communications  and  Intelligence 
(C^I)  activities.  Technical  and  engineering 
support  within  areas  of  competence  Is  provided  to 
ESP  Program  Owlets  IPOs }  and  other  ESV  elements 
to  perform  effective  acquisition  of  C3l  systems. 

The  areas  of  technical  competence  Include 
communications ,  command  and  control,  battle 
management.  Information  processing,  surveillance 
sensors.  Intelligence  data  collection  and  handling, 
solid  state  sciences,  electromagnetics,  and 
propagation,  and  electronic,  maintainability , 
and  compatibility. 


